The relationship of a typical software application to its run-time environment is growing more complex for at least four interrelated reasons. First, environments are themselves growing more complex. The rise of telecommunications often allows an application to take advantage of, or requires an application to be aware of, services and resources provided by remote computing devices located throughout the environment. Each remote device may present its own set of communications peculiarities, such as novel protocols or real-time response constraints. The number of possible interactions grows exponentially with the number of devices and applications involved in one computing task, and all of these interactions need to be managed efficiently. Second, environments may change their characteristics over time. For example, a given application may always need to secure a specific type of resource from a specific type of remote server, but the identities of the servers available to provide that type of resource may change moment by moment. At the same time, new services may be introduced and old services may disappear. Third, the application may need to run in multiple environments. The number of possible environments is proliferating as, for example, hardware and software platforms are optimized for particular uses. Even if an application's relationship to any one environment were to remain unchanged (unlikely for the reasons discussed above), the growth in number and diversity of possible environments leads to a demand for an increase in the flexibility, and thus the complexity, of the application's environmental interactions. Compounding the well known difficulties of developing an application to meet diverse requirements of diverse environments, a new environment may arise whose requirements were unforeseen when the application was developed. Fourth, applications themselves are becoming increasingly complex. For example, an application that formerly ran as one thread on a single, stand-alone computing device may now be reconstituted to run as multiple, interacting threads on multiple devices spread throughout the globe and connected by telecommunications links. One application may need to serve multiple purposes and must be able to present itself accordingly, for instance by providing a variable range of services dependent upon the sophistication of its current users. (In this situation, the requirements of the application's users are considered to be part of the application's environment.) As can be appreciated, these four reasons act in concert, the effects of each contributing, often in unpredictable ways, to the magnitude of the effects of the others.
As an especially pointed example of this situation, consider the case of an application designed to test other applications. (To differentiate between the application doing the testing and the application being tested, the former will be called the “test system” while the latter will be called the “application under test.”) The four reasons given above for increased complexity apply here to a heightened extent because the reasons may apply both to the relationship of the application under test to its run-time environment (its run-time environment including the test system) and to the relationship of the test system to its own run-time environment. As one example, to thoroughly exercise the application under test, the test system should exercise all aspects of the application under test's environmental interactions, through a range of possible environments and as those environments change. For any given environment, the test system may need to call upon different aspects of the application under test for different types of testing, such as basic variation testing, regression testing, and stress testing. This may require that the test system run multiple copies of the application under test at the same time, and each copy may be performing multiple tasks simultaneously. While the test system is coordinating all of these activities of the application under test, the test system still needs to handle its own complex interactions with its own environment, such as reporting test results, trapping execution errors, and detecting other potentially harmful aspects of the application under test's environmental relationship (such as dead locks and memory leaks). It is clear from this example that developing an application in the face of multiple, changing environments can be very challenging, and that the challenges are heightened when developing a test system.
Developers often address complexity in their application's relationships by designing aspects of the application that can be configured to meet changing circumstances. An application's configuration parameters can then be set when the application is run (or when it is compiled). Different sets of configurable parameters are set to reflect different aspects of the application's relationship to its run-time environment. Of course, when building flexibility into an application by means of configurable parameters, the developer predicts the range of needs in the possible set of run-time environments so that the configurable parameters, and the application's response to them, can be set.
Useful as configurable parameters are, it can still be extremely difficult to correctly initialize all of these parameters in a complex application's configuration. Subtle errors may arise from mismatches between one part of an application and other parts of the same application, or between the application and other applications in its environment. Mismatches include unexpected events, unplanned for sequences of events, data values outside the range of normalcy, updated behavior of one application not matched by updates in its peers, etc. Difficult as configuration is for one application, it is exponentially more difficult to configure multiple applications (such as the combination of a test system and an application under test) so that they interact with their environments and with each other in a predictable fashion. Adding to the difficulty of creating correct configurations, a configuration may change with time. Applications may be used in an environment, such as a testing environment, in which their configurations may be changed every time they operate. An application may need to run in an environment whose parameters are beyond the range envisaged by the application's developer and so beyond the range of its configurable parameters. In addition to these considerations, it is not desirable for an application developer to devote too much time to configuration issues: they distract the developer from working on issues at the core of the application and they may require environmental expertise foreign to the developer. Indeed, the expertise needed to correctly develop an application's configurable relationships may exist in no one person.
Developing an application's flexibility so that the application can respond correctly regardless of the environments within which it must run and then managing that flexibility in the face of multiple, changing environments are becoming increasingly burdensome. There is a need to contain the burgeoning complexity of an application's relationship to its run-time environment and to separate relationship issues from core application issues.